<HEAD> <TITLE> Implicit pointer semantics </TITLE> </HEAD> <BODY BACKGROUND=http://www.imaginary.com/~beek/gifs/bg.jpg TEXT=#000000 ALINK=#FFFF00 VLINK=#550000 LINK=#000099> <center> <H1> Implicit pointer semantics </H1> </center>
<p>
For those who know Sather:
<p>
LPC is very similar to Sather in this respect; Sather also distinguishes
between 'reference' and 'value' objects (Sather terminology).  In LPC,
strings, ints, and floats are 'value' objects, while the rest are
'reference' objects.
<p>
For those who don't:
<p>
Most LPC types (object, mapping, array, class; function as well, although
it's a moot point since they can't be modified) implicitly behave like
pointers.  This means that assigning an array value to a variable doesn't
actually copy the array, it simply gives you another way to reference
<i> the same array </i>.  For example, the following code:
<p>
<pre>
// the ({ ... }) operator creates a new array object.
// A _pointer_ to it is stored in x
mixed *x = ({ 1, 2 });                          
mixed *y;
// This makes y point to the _same_ array object as x
y = x;
// Modify the array object ...
y[0] = 3;
write(x[0]);
</pre>
<p>
prints 3, and not 1, even though we modified the array through y, and not x.
A copy() efun exists in the _Contrib package for explictly copying values.
<p>
The reason that LPC behaves in this way is mainly for efficiency reasons;
it is much more efficient to avoid copying values all the time, especially
for function calls, etc.
<p>
<HR> <ADDRESS> <A HREF=http://wagner.princeton.edu/~tim>  Tim Hollebeek </A> <p> <A HREF="http://www.imaginary.com/~beek/">  Beek </A>@ZorkMUD, Lima Bean, IdeaExchange, TMI-2, and elsewhere </ADDRESS>
